Мы уже писали о том, что "растянутый" кластер VMware HA Stretched Cluster прекрасно работает и поддерживается вместе с отказоустойчивыми хранилищами Virtual SAN. Также мы писали о документе с лучшими практиками по построению таких кластеров, для которых требуется обеспечивать максимальную производительность.

Однако многие задаются вопросом - а как планировать ширину канала между площадками таких растянутых кластеров, чтобы обеспечить необходимую пропускную способность для синхронизации узлов кластера VMware Virtual SAN? В помощь таким пользователям компания VMware выпустила интересный документ "VMware Virtual SAN Stretched Cluster Bandwidth Sizing Guidance", в котором даются конкретные параметры и формулы для расчета необходимой пропускной способности между площадками.

Архитектура растянутого кластера в общем случае выглядит так:

Таким образом, имеет место быть 2 связи - между двумя площадками как узлами кластера, а также между каждой из площадок и компонентом Witness, следящим за состоянием каждой из площадок и предотвращающим сценарии Split Brain.

Для этих соединений рекомендуются следующие параметры:

Как известно, реальный трафик состоит из отношения операций чтения и записи, которое зависит от характера нагрузки. Например, в VDI-среде это отношение составляет примерно 30/70, то есть 30% - это операции чтения (read), а 70% - операции записи (write).

В среде растянутого кластера данные виртуальной машины всегда читаются с локальных узлов VSAN - это называется Read Locality. Ну а для операций записи, само собой, нужна определенная пропускная способность на другую площадку. Она рассчитывается как:

B = Wb * md * mr

где:

• Wb - полоса записи данных.
• md - множитель данных, он зависит от потока метаданных кластера VSAN и сервисных операций. VMware рекомендует использовать значение 1,4 для этого параметра.
• mr - множитель ресинхронизации. Для целей ресинхронизации VMware рекомендует заложить в канал еще 25%, то есть использовать значение этого параметра 1,25.

Например, рабочая нагрузка у вас составляет 10 000 IOPS на запись (10 тысяч операций в секунду). Возьмем типичный размер операции записи в 4 КБ и получим параметр Wb:

Wb = 10 000 * 4KB = 40 MB/s = 320 Mbps

Мегабайты в секунду переводятся в мегабиты умножением на 8. Ну и заметим, что требование канала по записи нужно умножать на 1,4*1,25 = 1,75. То есть канал нужно закладывать почти в 2 раза больше от требований по записи данных.

Теперь считаем требуемую пропускную способность канала между площадками:

B = Wb * md * mr = 320 Mbps * 1,4 * 1,25 = 560 Mbps

Ну а в самом документе вы найдете еще больше интересных расчетов и примеров.

Мы часто пишем о решении для создания отказоустойчивых хранилищ StarWind Virtual SAN, которое помогает существенно сэкономить при построении инфраструктуры хранения виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Вот в этой статье мы писали о том, что 3 узла для кластера - это лучше, надежнее и экономнее (в пересчете на единицу емкости), чем 2. Это обеспечивает аптайм хранилищ до 99.9999%. Но иногда и 2 узла вполне достаточно с точки зрения экономии на программном и аппаратном обеспечении.

Приходите на бесплатный вебинар "VMware and Fault-Tolerance. Which is Better for Your Backup: 2 or 3 Nodes Hyperconverged?", чтобы узнать, сколько узлов для кластера нужно использовать и в каких ситуациях.

Бесплатный вебинар пройдет 10 ноября в 22-00 по московскому времени. Регистрируйтесь!

На блоге vSphere появилась отличная статья о сервисах семейства vCenter Server Watchdog, которые обеспечивают мониторинг состояния различных компонентов vCenter, а также их восстановление в случае сбоев. Более подробно о них также можно прочитать в VMware vCenter Server 6.0 Availability Guide.

Итак, сервисы Watchdog бывают двух типов:

• PID Watchdog - мониторит процессы, запущенные на vCenter Server.
• API Watchdog - использует vSphere API для мониторинга функциональности vCenter Server.

Сервисы Watchdog пытаются рестартовать службы vCenter в случае их сбоя, а если это не помогает, то механизм VMware перезагружает виртуальную машину с сервером vCenter на другом хосте ESXi.

PID Watchdog

Эти службы инициализируются во время инициализации самого vCenter. Они мониторят только службы, которые активно работают, и если вы вручную остановили службу vCenter, поднимать он ее не будет. Службы PID Watchdog, контролируют только лишь наличие запущенных процессов, но не гарантируют, что они будут обслуживать запросы (например, vSphere Web Client будет обрабатывать подключения) - этим занимается API Watchdog.

Вот какие сервисы PID Watchdog бывают:

• vmware-watchdog - этот watchdog обнаруживает сбои и перезапускает все не-Java службы на сервере vCenter Server Appliance (VCSA).
• Java Service Wrapper - этот watchdog обрабатывает сбои всех Java-служб на VCSA и в ОС Windows.
• Likewise Service Manager - данный watchdog отвечает за обработку отказов всех не-Java служб сервисов platform services.
• Windows Service Control Manager - отвечает за обработку отказов всех не-Java служб на Windows.

vmware-watchdog

Это шелл-скрипт (/usr/bin/watchdog), который располагается на виртуальном модуле VCSA. Давайте посмотрим на его запущенные процессы:

mgmt01vc01.sddc.local:~ # ps -ef | grep vmware-watchdog

root      5767     1  0 16:20 ?        00:00:00 /bin/sh /usr/bin/vmware-watchdog -s rhttpproxy -u 30 -q 5 /usr/sbin/rhttpproxy -r /etc/vmware-rhttpproxy/config.xml -d /etc/vmware-rhttpproxy/endpoints.conf.d -f /etc/vmware-rhttpproxy/endpo
root      7930     1  0 16:21 ?        00:00:00 /bin/sh /usr/bin/vmware-watchdog -s vws -u 30 -q 5 /usr/lib/vmware-vws/bin/vws.sh
root      8109     1  0 16:21 ?        00:00:11 /bin/sh /usr/bin/vmware-watchdog -s syslog -u 30 -q 5 -b /var/run/rsyslogd.pid /sbin/rsyslogd -c 5 -f /etc/vmware-rsyslog.conf
root      8266     1  0 16:21 ?        00:00:11 /bin/sh /usr/bin/vmware-watchdog -b /storage/db/vpostgres/postmaster.pid -u 300 -q 2 -s vmware-vpostgres su -s /bin/bash vpostgres -c 'LD_LIBRARY_PATH=/opt/vmware/vpostgres/curre
root      9422     1  0 16:21 ?        00:00:00 /bin/sh /usr/bin/vmware-watchdog -a -s vpxd -u 3600 -q 2 /usr/sbin/vpxd
root     13113     1  0 16:22 ?        00:00:00 /bin/sh /usr/bin/vmware-watchdog -s vsan-health -u 600 -q 10 su vsan-health -c '/opt/vmware/bin/vmware-vsan-health /usr/lib/vmware-vpx/vsan-health/VsanHealthServer.py -p 8006'
root     28775 19850  0 20:42 pts/0    00:00:00 grep vmware-watchdog

В понятном виде это можно представить так:

Давайте разберем эти параметры на примере наиболее важной службы VPXD:

-a
-s vpxd
-u 3600
-q 2

Это означает, что:

vpxd (-s vpxd) запущен (started), для него работает мониторинг, и он будет перезапущен максимум дважды в случае сбоя (-q 2). Если это не удастся в третий раз при минимальном аптайме 1 час (-u 3600 - число секунд), виртуальная машина будет перезагружена (-a).

Полный список параметров представлен ниже:

-d = DAEMONIZE
-n = QUIET
-b = BG_PROC-s = START
-k = STOP
-r = QUERY
-a = REBOOT_FLAG
-u = MIN_UPTIME
-q = MAX_QUICK_FAILURES
-t = MAX_TOTAL_FAILURES
-i = IMMORTAL
-c = CLEANUP_CMD
-f = EXIT_CLEANUP_CMD

Java Service Wrapper

Он основан на Tanuki Java Service Wrapper и нужен, чтобы обнаруживать сбои в Java-службах vCenter (как обычного, так и виртуального модуля vCSA). Вот какие службы мониторятся:

mgmt01vc01.sddc.local:~ # ps -ef | grep tanuki

cm        6331  6324  0 16:20 ?        00:00:37 /usr/java/jre-vmware/bin/vmware-cm -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -Dlog4j.configuration=cm-log4j.properties -Dxml.config=ht
root      6876  6869  0 16:20 ?        00:00:50 /usr/java/jre-vmware/bin/vmware-cis-license -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dorg.apache.catalina.startup.EXIT_ON_INIT_FAILURE=TRUE -XX:+ForceTimeHighRe
root      7267  7258  1 16:21 ?        00:03:45 /usr/java/jre-vmware/bin/vmware-sca -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/lo
root      7634  7627  0 16:21 ?        00:00:29 /usr/java/jre-vmware/bin/vmware-syslog-health -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -DlogDir=/var/log/vmware/syslog -Dlog4j.config
1002      7843  7836  0 16:21 ?        00:01:08 /usr/java/jre-vmware/bin/vmware-vapi-endpoint -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -Dlog4j.configuration=file:/etc/vmware-vapi//e
root      8453  8433  1 16:21 ?        00:02:55 /usr/java/jre-vmware/bin/vmware-invsvc -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dvim.logdir=/var/log/vmware/invsvc -XX:+ForceTimeHighResolution -XX:+ParallelRefP
root     10410 10388  0 16:22 ?        00:00:54 /usr/java/jre-vmware/bin/vmware-sps -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dxml.config=../conf/sps-spring-config.xml -Dpbm.config=../conf/pbm-spring-config.xml
1007     11099 11088  0 16:22 ?        00:01:27 /usr/java/jre-vmware/bin/vmware-vpx-workflow -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -ea -Dlog4j.configuration=conf/workflow.log4j.p
root     23423 19850  0 20:41 pts/0    00:00:00 grep tanuki

Если Java-приложение или JVM (Java Virtual Machine) падает, то перезапускается JVM и приложение.

Likewise Service Manager

Это сторонние средства Likewise Open stack от компании BeyondTrust, которые мониторят доступность следующих служб, относящихся к Platform Services среды vCenter:

• VMware Directory Service (vmdir)
• VMware Authentication Framework (vmafd, который содержит хранилище сертификатов VMware Endpoint Certificate Store, VECS)
• VMware Certificate Authority (vmca)

Likewise Service Manager следит за этими сервисами и перезапускает их в случае сбоя или если они вываливаются.

mgmt01vc01.sddc.local:~ # /opt/likewise/bin/lwsm list | grep vm
vmafd       running (standalone: 5505)
vmca        running (standalone: 5560)
vmdir        running (standalone: 5600)

Вместо параметра list можно также использовать start и stop, которые помогут в случае, если одна из этих служб начнет подглючивать. Вот полный список параметров Likewise Service Manager:

list          List all known services and their status
autostart       Start all services configured for autostart
start-only <service>    Start a service
start <service>            	Start a service and all dependencies
stop-only <service>    Stop a service
stop <service>             Stop a service and all running dependents
restart <service>          Restart a service and all running dependents
refresh <service>         Refresh service's configuration
proxy <service>           Act as a proxy process for a service
info <service>             Get information about a service
status <service>          Get the status of a service
gdb <service>              Attach gdb to the specified running service

А вот таким образом можно узнать детальную информацию об одном из сервисов:

mgmt01vc01.sddc.local:~ # /opt/likewise/bin/lwsm info vmdir
Service: vmdir
Description: VMware Directory Service
Type: executable
Autostart: yes
Path: /usr/lib/vmware-vmdir/sbin/vmdird
Arguments: '/usr/lib/vmware-vmdir/sbin/vmdird' '-s' '-l' '0' '-f' '/usr/lib/vmware-vmdir/share/config/vmdirschema.ldif'
Environment:
Dependencies: lsass dcerpc vmafd

Помните также, что Likewise Service Manager отслеживает связи служб и гасит/поднимает связанные службы в случае необходимости.

API Watchdog

Этот сервис следит через vSphere API за доступностью самого важного сервиса vCenter - VPXD. В случае сбоя, этот сервис постарается 2 раза перезапустить VPXD, и если это не получится - он вызовет процедуру перезапуска виртуальной машины механизмом VMware HA.

Эти службы инициализируются только после первой загрузки после развертывания или обновления сервисов vCenter. Затем каждые 5 минут через vSphere API происходит аутентификация и опрос свойства rootFolder для корневой папки в окружении vCenter.

Далее работает следующий алгоритм обработки отказов:

• Первый отказ = Restart Service
• Второй отказ = Restart Service
• Третий отказ = Reboot Virtual Machine
• Сброс счетчика отказов происходит через 1 час (3600 секунд)

Перед рестартом сервиса VPXD, а также перед перезагрузкой виртуальной машины, служба API Watchdog генерирует лог, который можно исследовать для решения проблем:

• storage/core/*.tgz - на виртуальном модуле VCSA
• C:\ProgramData\VMware\vCenterServer\data\core\*.tgz - не сервере vCenter

Конфигурация сервиса API Watchdog (который также называется IIAD - Interservice Interrogation and Activation Daemon) хранится в JSON-формате в файле "iiad.json", который можно найти по адресу /etc/vmware/ на VCSA или C:\ProgramData\VMware\vCenterServer\cfg\iiad.json на Windows-сервер vCenter:

mgmt01vc01.sddc.local:/ # cat /etc/vmware/iiad.json
{
"requestTimeout": 20,
"hysteresisCount": 4,
"remediatedHysteresisCount": 6,
"rebootShellCmd": null,
"restartShellCmd": null,
"maxTotalFailures": 50,
"needShellOnWin": true,
"watchdogDisabled": false,
"vpxd.watchdogDisabled": false,
"createSupportBundle": true,
"automaticServiceRestart": true,
"automaticSystemReboot": false,
"maxSingleRestarts": 3,
"maxSingleFailures": 2
}

Вот что это значит:

• requestTimeout – дефолтный таймаут для запросов по умолчанию.
• hysteresisCount – позволяет отказам постепенно "устаревать" - каждое такое значение счетчика при отказе, число отсчитываемых отказов будет уменьшено на один.
• rebootShellCmd – указанная пользователем команда, которая будет исполнена перед перезапуском ВМ.
• restartShellCmd – указанная пользователем команда, которая будет исполнена перед перезапуском сервиса.
• maxTotalFailures – необходимое число отказов по всем службам, которое должно случиться, чтобы произошел перезапуск виртуальной машины.
• needShellOnWin – определяет, нужно ли запускать сервис с параметром shell=True на Windows.
• watchdogDisabled – позволяет отключить API Watchdog.
• vpxd.watchdogDisabled – позволяет отключить API Watchdog для VPXD.
• createSupportBundle – нужно ли создавать support-бандл перед перезапуском сервиса или рестартом ВМ.
• automaticServiceRestart – нужно ли перезапускать сервис при обнаружении сбоя или просто записать это в лог.
• automaticSystemReboot – нужно ли перезапускать ВМ при обнаружении сбоя или просто записать в лог эту рекомендацию.
• maxSingleRestarts – верхний лимит попыток перезапуска упавшего сервиса.
• maxSingleFailures – число отказов, требуемой для срабатывания действия по перезапуску сервиса.

Также сервис IIAD перед перезапуском сервисов или виртуальной машины генерирует лог по адресу:

• /var/log/vmware/iiad/* - на виртуальном модуле VCSA
• %VMWARE_LOG_DIR%/iiad/* - в ОС Windows

Вот такой небольшой deep dive в службы доступности сервисов vCenter:)

20 октября компания StarWind, производитель решения номер 1 - StarWind Virtual SAN, предназначенного для создания отказоустойчивой инфраструктуры хранилищ под виртуальные машины VMware vSphere и Microsoft Hyper-V, проводит интересный вебинар "VMware and Fault-Tolerance: Why Are 3 Nodes Better Than 2 for Hyper-Converged Architecture?".

Мероприятие пройдет 20 октября в 22-00 по московскому времени.

На вебинаре будет рассказано, почему в гиперконвергентной инфраструктуре лучше иметь 3 узла для организации отказоустойчивых хранилищ. Напомним, что мы уже писали об этой архитектуре вот тут.

Зарегистрируйтесь!

Недавно Cormac Hogan написал интересный пост о том, как нужно настраивать "растянутый" между двумя площадками HA-кластер на платформе VMware vSphere, которая использует отказоустойчивую архитектуру Virtual SAN.

Напомним, как это должно выглядеть (два сайта на разнесенных площадках и witness-хост, который обрабатывает ситуации разделения площадок):

Основная идея такой конфигурации в том, что при отказе отдельного хоста или его компонентов виртуальная машина обязательно должна запуститься на той же площадке, где и была до этого, а в случае отказа всей площадки (аварии) - машины должны быть автоматически запущены на резервном сайте.

Откроем настройки кластера HA. Во-первых, он должен быть включен (Turn on vSphere HA), и средства обнаружения сетевых отказов кластера (Host Monitoring) также должны быть включены:

Host Monitoring позволяет хостам кластера обмениваться сигналами доступности (heartbeats) и в случае отказа предпринимать определенные действия с виртуальными машинами отказавшего хоста.

Для того, чтобы виртуальная машина всегда находилась на своей площадке в случае отказа хоста (и использовала локальные копии данных на виртуальных дисках VMDK), нужно создать Affinity Rules, которые определяют правила перезапуска ВМ на определенных группах хостов в рамках соответствующей площадки. При этом эти правила должны быть "Soft" (так называемые should rules), то есть они будут соблюдаться при возможности, но при отказе всей площадки они будут нарушены, чтобы запустить машины на резервном сайте.

Далее переходим к настройке "Host Hardware Monitoring - VM Component Protection":

На данный момент кластер VSAN не поддерживает VMCP (VM Component Protection), поэтому данную настройку надо оставить выключенной. Напомним, что VMCP - это новая функция VMware vSphere 6.0, которая позволяет восстанавливать виртуальные машины на хранилищах, которые попали в состояние All Paths Down (APD) или Permanent Device Loss (PDL). Соответственно, все что касается APD и PDL будет выставлено в Disabled:

Теперь посмотрим на картинку выше - следующей опцией идет Virtual Machine Monitoring - механизм, перезапускающий виртуальную машину в случае отсутствия сигналов от VMware Tools. Ее можно использовать или нет по вашему усмотрению - оба варианта полностью поддерживаются.

На этой же кариинке мы видим настройки Host Isolation и Responce for Host Isolation - это действие, которое будет предпринято в случае, если хост обнаруживает себя изолированным от основной сети управления. Тут VMware однозначно рекомендует выставить действие "Power off and restart VMs", чтобы в случае отделения хоста от основной сети он самостоятельно погасил виртуальные машины, а мастер-хост кластера HA дал команду на ее восстановление на одном из полноценных хостов.

Далее идут настройки Admission Control:

Здесь VMware настоятельно рекомендует использовать Admission Control по простой причине - для растянутых кластеров характерно требование самого высокого уровня доступности (для этого он, как правило, и создается), поэтому логично гарантировать ресурсы для запуска виртуальных машин в случае отказа всей площадки. То есть правильно было бы зарезервировать 50% ресурсов по памяти и процессору. Но можно и не гарантировать прям все 100% ресурсов в случае сбоя, поэтому можно здесь поставить 30-50%, в зависимости от требований и условий работы ваших рабочих нагрузок в виртуальных машинах.

Далее идет настройка Datastore for Heartbeating:

Тут все просто - кластер Virtual SAN не поддерживает использование Datastore for Heartbeating, но такого варианта тут нет :) Поэтому надо выставить вариант "Use datastores only from the secified list" и ничего из списка не выбирать (убедиться, что ничего не выбрано). В этом случае вы получите сообщение "number of vSphere HA heartbeat datastore for this host is 0, which is less than required:2".

Убрать его можно по инструкции в KB 2004739, установив расширенную настройку кластера das.ignoreInsufficientHbDatastore = true.

Далее нужно обязательно установить кое-какие Advanced Options. Так как кластер у нас растянутый, то для обнаружения наступления события изоляции нужно использовать как минимум 2 адреса - по одному на каждой площадке, поэтому расширенная настройка das.usedefaultisolationaddress должна быть установлена в значение false. Ну и нужно добавить IP-адреса хостов, которые будут пинговаться на наступление изоляции хост-серверов VMware ESXi - это настройки das.isolationaddress0 и das.isolationaddress1.

Таким образом мы получаем следующие рекомендуемые настройки растянутого кластера HA совместно с кластером Virtual SAN:

Ну и должны быть добавлены следующие Advanced Settings:

Более подробно об этом всем написано в документе "Virtual SAN 6.1 Stretched Cluster Guide".

Не так давно мы писали о гиперконвергентной платформе StarWind Hyper-Converged Platform (H-CP), которая позволяет построить полноценную ИТ-инфраструктуру небольшого предприятия на базе продуктов компаний StarWind, Veeam, VMware и Microsoft. H-CP поставляется в виде уже готовых к использованию серверов с предустановленными компонентами от соответствующих вендоров.

Теперь у StarWind появилась специальная страница, посвященная Hyper-Converged Platform. Ну и, кроме этого, об H-CP можно узнать из вот этого видео:

Строится все это на базе следующих аппаратных платформ:

Подробно об аппаратных характеристиках платформы H-CP от StarWind можно узнать из этого документа.

На проходящей сейчас конференции VMworld 2015 было сделано множество интересных анонсов (впрочем, как и всегда). Конечно же, мы расскажем о всех тех, что достойны внимания. Одна из самых интересных новостей - это анонс новой версии решения для создания кластеров хранилищ VMware Virtual SAN 6.1.

Давайте взглянем на новые возможности этого решения:

1. Virtual SAN Stretched Cluster.

Теперь VSAN будет позволять создавать географически "растянутый" кластер хранилищ между датацентрами, продолжая обеспечивать функции отказоустойчивости. Репликация данных при этом работает с синхронном режиме.

2. Virtual SAN for Remote Office / Branch Office (ROBO)

В VSAN теперь появилась возможность развертывать множество двухузловых кластеров хранилищ, которыми можно централизованно управлять из одной консоли отдельного VMware vCenter Server, предназначенного для этой задачи. Этот сценарий подходит для компаний с большим числом небольших филиалов:

3. Virtual SAN Replication with vSphere Replication

Virtual SAN 6.1 теперь может использовать технологию vSphere Replication для асинхронной репликации данных на любые расстояния в комбинации с VMware Site Recovery Manager (SRM), чтобы получилось полностью законченное решения для восстановления инфраструктуры после сбоев.

Например, можно создать синхронно реплицируемый растянутый кластер хранилищ на расстояниях с latency менее 5 мс, а средствами vSphere Replication откидывать данные в географически удаленный датацентр:

4. Поддержка Multi-Processor Fault Tolerance (SMP-FT).

Теперь виртуальные машины, защищенные технологией FT, полностью поддерживаются со стороны VMware Virtual SAN 6.1, то есть кластер непрерывной доступности из виртуальных машин теперь защищен как со стороны вычислительных ресурсов, так и со стороны хранилищ.

5. Поддержка Windows Server Failover Clustering (WSFC) and Oracle Real Application Cluster (RAC).

В новой версии VSAN теперь поддерживаются технологии кластеризации от Oracle и Microsoft. Для Oracle RAC можно запускать несколько экземпляров Oracle RDBMS на одном хранилище. Точно так же можно использовать и кластеры Microsoft WSFC поверх хранилищ Virtual SAN:

6. Максимальная производительность и высокая скорость отклика.

Здесь было сделано 2 серьезных улучшения:

• Поддержка ULLtraDIMM SSD хранилищ, которые втыкаются в канал оперативной памяти (слоты DIMM), работающие с очень быстрым откликом на запись (менее 5 микросекунд). Это позволяет сделать хост All Flash с емкостью на 12 ТБ в форм-факторе блейд-сервера с троекратно большей производительностью, чем у внешних массивов.
• NVMe – интерфейс Non-Volatile Memory Express (NVMe), который был специально разработан для SSD, чтобы максимально распараллеливать операции на программном и аппаратном уровне. В тестах VMware, использующих эту технологию, было получено 3,2 миллиона IOPS на 32-узловом кластере при примерно 100 тысячах операций в секунду на одном хост-сервере ESXi.

7. Virtual SAN Health Check Plug-in.

Теперь плагин, который был ранее доступен только на VMware Labs, стал частью решения VMware Virtual SAN 6.1. Теперь вся необходимая информация о жизнедеятельности кластера хранилищ видна в VMware vSphere Web Client:

8. Virtual SAN Management Pack for vRealize Operations.

Теперь для решения vRealize Operations есть отдельный Virtual SAN Management Pack, который позволяет осуществлять мониторинг кластера хранилищ и своевременно решать возникающие проблемы:

Более подробно о решении VMware Virtual SAN 6.1 можно узнать на этой странице. О доступности решения для загрузки будет объявлено несколько позже.

В ближайшее время мы расскажем еще о нескольких интересных анонсах с VMworld 2015 - stay tuned.

Компания StarWind, известная своим продуктом StarWind Virtual SAN для создания программных отказоустойчивых хранилищ, выпустила интересный документ о своей журналируемой файловой системе - "LSFS container technical description".

Напомним, что файловая система LSFS изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины. Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.

Помимо этого, LSFS имеет следующие полезные функции:

• встроенная поддержка снапшотов и точек восстановления хранилищ (автоматически они делаются каждые 5 минут)
• поддержка непрерывной дефрагментации (она идет в фоне)
• дедупликация данных "на лету" (то есть, перед записью на диск)
• улучшения производительности за счет комбинирования операций записи
• поддержка overprovisioning
• использование технологии снапшотов и техник отслеживания изменений при синхронизации HA-узлов

Обо всем этом и многом другом вы можете почитать в документе "LSFS container technical description".

Многие из вас знают о решении StarWind Virtual SAN, предназначенном для создания отказоустойчивых хранилищ. Но не все в курсе, что у StarWind есть виртуальный модуль Virtual SAN OVF (ссылка на его загрузку высылается по почте), который представляет собой шаблон виртуальной машины в формате OVF готовый к развертыванию на платформе VMware vSphere.

Недавно компания StarWind выпустила документ Virtual SAN OVF Deployment Guide, в котором описана процедура развертывания данного виртуального модуля.

Поскольку Microsoft на уровне лицензии запрещает распространение таких виртуальных модулей с гостевой ОС Windows в формате виртуальных дисков VMDK, придется сделать несколько дополнительных операций по развертыванию, а именно:

1. Запустить StarWind V2V Converter.
2. Преобразовать VHDX-диски в формат VMDK.
3. Поместить VMDK и OVF в одну папку.
4. Развернуть OVF на сервере VMware ESXi.
5. Заполнить поля IP-адреса для включения машины в виртуальную сеть.
6. Подождать окончания процесса создания и конфигурации виртуальной машины.

Больше подробностей о виртуальном модуле StarWind Virtual SAN OVF вы найдете в документе.

Совсем недавно компания StarWind Software, производитель средства номер 1 для создания отказоустойчивых программных хранилищ под виртуальные машины VMware и Microsoft - Virtual SAN, выпустила интересный документ по его бесплатному изданию - "StarWind Virtual SAN Free Getting Started".

Напомним, что полностью бесплатный продукт StarWind Virtual SAN Free позволяет превратить два новых или имеющихся у вас сервера в отказоустойчивый кластер хранения (с полностью дублированными зеркалированными узлами), который может служить для:

• размещения виртуальных машин Microsoft Hyper-V (NFS/SMB3)
• размещения виртуальных машин VMware vSphere (NFS)
• размещения баз данных MS SQL Server (SMB3)
• создания отказоустойчивого файлового сервера (SMB3/NFS)

Кстати, StarWind Virtual SAN Free - единственное решение, которое позволяет создавать HA-кластер из двух узлов неограниченной емкости абсолютно бесплатно. Более подробно об отличиях бесплатной и коммерческой версий продукта можно почитать вот в этом документе.

На днях компания VMware выпустила интересный документ "VMware vSphere Metro Storage Cluster Recommended Practices" о построении архитектуры распределенного кластера VMware HA/DRS. Теперь в документе учтены все самые последние изменения, которые произошли в этом плане после выхода VMware vSphere 6.

Документ состоит из двух частей: в первой части рассказывается о том, как правильно спроектировать кластер vMSC и настроить платформу VMware vSphere соответствующим образом:

Во второй части подробно описаны различные сценарии сбоев и их обработка кластером vMSC в вашей распределенной виртуальной инфраструктуре:

В документе описаны следующие виды сбоев:

• Отказ одного хоста в основном датацентре
• Изоляция одного хоста в основном датацентре
• Разделение пула виртуальных хранилищ
• Разделение датацентра на сегменты (сети хостов и сети хранилищ)
• Отказ дисковой полки в основном ЦОД
• Полный отказ всех хранилищ в основном датацентре
• Потеря устройств (полный выход из строя, выведение из эксплуатации) - Permanent Device Loss (PDL)

Понятное дело, что документ обязателен к прочтению, если вы планируете строить распределенную инфраструктуру для ваших виртуальных машин на платформе VMware vSphere 6.0.

Совсем недавно компания VMware выпустила полезный документ "VMware Horizon View 6.0.2 and VMware Virtual SAN 6.0 Hybrid", описывающий эталонную архитектуру инфраструктуры виртуальных ПК Horizon View 6, которые хранятся в кластере отказоустойчивости VMware Virtual SAN 6.0, построенном на базе хостов VMware ESXi.

В документе рассмотрено тестирование производительности 12-узлового кластера Virtual SAN на базе серверов Supermicro в рамках следующей логической архитектуры:

Подробная конфигурация хостов:

В целом инфраструктура тестирования выглядела так:

Для тестов использовалось средство Login VSI (о нем мы уже много писали), которое поставляется вместе с методологией тестирования:

Сводные результаты тестов:

Для получения более подробной информации о результатах по каждому тесту, используемых сценариях и конфигурациях обращайтесь к документу. Все 38 страниц полны картинок, графиков и табличек с цифрами - док составлен очень по делу. Для тех, кто планирует VDI на базе Virtual SAN очень полезный референс, как в плане архитектуры, так и в плане производительности.

Какое-то время назад мы писали о том, что компания VMware выпустила документ об обеспечении непрерывной работы сервера управления VMware vSphere - vCenter Server 5.5 Availability Guide. Совсем недавно VMware выпустила обновление этого документа - vCenter Server 6.0 Availability Guide.

Если вкратце, то компоненты vCenter предлагается защищать с помощью следующих решений:

1. Кластер высокой доступности VMware HA и сервис слежения за vCenter - Watchdog.

Сервис HA автоматически перезапускает виртуальную машину с vCenter отказавшего сервера на другом хосте кластера, а сервис Watchdog (он есть как на обычном vCenter, так и на vCenter Server Appliance) следит за тем, чтобы основная служба vCenter работала и отвечала, и запускает/перезапускает ее в случае сбоя.

2. Защита средствами VMware Fault Tolerance.

Теперь технология VMware FT в VMware vSphere 6.0 позволяет защищать ВМ с несколькими vCPU, поэтому данный способ теперь подходит для обеспечения непрерывной доступности сервисов vCenter и мгновенного восстановления в случае сбоя оборудования основного хоста ESXi.

3. Сторонние утилиты, использующие VMware Application Monitoring API.

Компания VMware предоставляет специализированный API, который могут использовать партнеры для создания решений, защищающих приложения в гостевой ОС, в частности, сервис vCenter. Одно из таких приложений - Symantec ApplicationHA. Оно полностью поддерживает vCenter, имеет специализированного агента и перезапускает нужные службы в случае сбоя или зависания сервиса.

4. Средства кластеризации на уровне гостевой ОС (с кворумным диском).

Это один из древнейших подходов к защите сервисов vCenter. О нем мы писали еще вот тут.

Для организации данного типа защиты потребуется основная и резервная ВМ, которые лучше разместить на разных хостах vCenter. С помощью кластера Windows Server Failover Clustering (WSFC) организуется кворумный диск, общий для виртуальных машин, на котором размещены данные vCenter. В случае сбоя происходит переключение на резервную ВМ, которая продолжает работу с общим диском. Этот метод полностью поддерживается с vCenter 6.0:

Кстати, в документе есть пошаговое руководство по настройке кластера WSFC для кластеризации vCenter 6.0 (не забудьте потом, где его искать).

Ну и в заключение, сводная таблица по функциям и преимуществам приведенных методов:

Далее идет описание средств высокой доступности в Enterprise-инфраструктуре с несколькими серверами vCenter, где компоненты PSC (Platform Services Controller) и vCenter разнесены по разным серверам. Схема с использованием балансировщика:

Обратите внимание, что для PSC отказоустойчивость уже встроена - они реплицируют данные между собой.

Та же схема, но с кластеризованными серверами vCenter средствами технологии WSFC:

Использование географически распределенных датацентров и сервисов vCenter в них в едином домене доступа SSO (Single Sign-On) за счет технологии Enhanced Linked Mode (каждый сайт независим):

То же самое, но со схемой отказоустойчивости на уровне каждой из площадок:

Ну и напоследок 2 дополнительных совета:

1. Используйте Network Teaming для адаптеров vCenter (физических или виртуальных) в режиме отказоустойчивости, подключенные к дублирующим друг друга сетям.

2. Используйте Anti-affinity rules кластера HA/DRS, чтобы основная и резервная машина с vCenter не оказались на одном хосте VMware ESXi.

Да, и не забывайте о резервном копировании и репликации виртуальной машины с vCenter. Сделать это можно либо средствами Veeam Backup and Replication 8, либо с помощью VMware vSphere Replication/VMware vSphere Data Protection.

Некоторое время назад мы писали про обработку гипервизором VMware vSphere таких состояний хранилища ВМ, как APD (All Paths Down) и PDL (Permanent Device Loss). Вкратце: APD - это когда хост-сервер ESXi не может получить доступ к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды, а PDL - это когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось.

Так вот, в новой версии VMware vSphere 6.0 появился механизм VM Component Protection (VMCP), который позволяет обрабатывать эти ситуации со стороны кластера высокой доступности VMware HA в том случае, если в нем остались другие хосты, имеющие доступ к виртуальной машине, оставшейся без "хост-хозяина".

Для того чтобы это начало работать, нужно на уровне кластера включить настройку "Protect against Storage Connectivity Loss":

Далее посмотрим на настройки механизма Virtual Machine Monitoring, куда входят и настройки VM Component Protection (VMCP):

С ситуацией PDL все понятно - хост больше не имеет доступа к виртуальной машине, и массив знает об этом, то есть вернул серверу ESXi соответствующий статус - в этом случае разумно выключить процесс машины на данном хосте и запустить ВМ на других серверах. Тут выполняется действие, указанное в поле Response for a Datastore with Permanent Device Loss (PDL).

Со статусом же APD все происходит несколько иначе. Поскольку в этом состоянии мы не знаем пропал ли доступ к хранилищу ВМ ненадолго или же навсегда, происходит все следующим образом:

• возникает пауза до 140 секунд, во время которой хост пытается восстановить соединение с хранилищем
• если связь не восстановлена, хост помечает датастор как недоступный по причине APD Timout
• далее VMware HA включает счетчик времени, который длится ровно столько, сколько указано в поле Delay for VM failover for APD (по умолчанию - 3 минуты)
• по истечении этого времени начинается выполнение действия Response for a Datastore with All Paths Down (APD), а само хранилище помечается как утраченное (NO_Connect)

У такого механизма работы есть следующие особенности:

• VMCP не поддерживает датасторы Virtual SAN - они будут просто игнорироваться.
• VMCP не поддерживает Fault Tolerance. Машины, защищенные этой технологией, будут получать перекрывающую настройку не использовать VMCP.
• VMCP не поддерживает хранилища Virtual Volumes.
• VMCP не работает с томами Raw Device Mapping (RDM).

Ну и надо помнить, что VM Component Protection (VMCP), как и многие прочие новые возможности vSphere 6, настраивается только через vSphere Web Client.

На днях компания VMware выпустила документ "VMware AlwaysOn Desktop", который будет интересен всем тем, кто использует или планирует инфраструктуру виртуальных ПК на базе решения VMware Horizon View. Особенно, если вы хотите добиться непрерывной доступности ваших десктопов и приложений.

В данном документе из 30 страниц рассматривается VDI-архитектура, обеспечивающая постоянную доступность виртуальных ПК за счет Active/Active-конфигурации датацентров (View Pods). В каждом из сайтов есть два кластера - для управления (Active Directory, View Connection Manager, Security Server и т.п.) и для размещения, собственно, виртуальных ПК. Кроме того, есть третий сайт (Site C), который содержит legacy-приложения, к которым происходит доступ с машин как первого, так и второго сайтов.

В синхронизированном состоянии (за счет ПО для репликации) находятся как мастер-образы виртуальных ПК (base image), так и пользовательские данные, чтобы пользователи VDI-инфраструктуры могли получить к ним доступ со стороны любого сайта. Интересно, что репликацию предлагается организовать средствами продукта Veeam Backup and Replication.

В документе рассматривается не только реализация этой архитектуры, но и такие вещи как мониторинг состояния инфраструктуры средствами VMware vCenter Operations Manager for View, а также обеспечение безопасности средствами продуктов vShield.

Использованное аппаратное обеспечение:

Разделы документа:

• About, introduction and audience
• Business Case
• What is the AlwaysOn Desktop
• User Profiles
• AlwaysOn Desktop Lab Validation
• AlwaysOn Desktop Logical Architecture Overview
• Key Components of the Architecture
• Overview of Architecture
• Validation Results
• Conclusion

На сайте проекта VMware Labs, про который мы регулярно пишем, появилась очень полезная утилита VM Resource and Availability Service (vRAS). Она позволяет провести анализ "что если" (what-if analysis) в плане последствий для инфраструктуры при различных отказах.

Вы можете симулировать отказ одного или нескольких хостов VMware ESXi в кластере, чтобы узнать:

• сколько виртуальных машин будут гарантированно перезапущены на хостах кластера HA
• сколько машин не смогут запуститься, так как не хватит емкости выживших хостов
• сколько машин будут испытывать нехватку вычислительных мощностей и будут работать не в полную силу после рестарта на других хостах

Последний пункт особенно важен для тех инфраструктур, где у машин не установлен параметр Reservation, то есть администраторы знают, что машины перезапустятся в случае сбоя все, но не знают, сколько из них будут испытывать проблемы с производительностью.

Очевидно, что данная информация позволит вам сделать выводы о текущей надежности виртуальной инфраструктуры и принять решение о вводе в строй дополнительных мощностей.

Кстати, VM Resource and Availability Service - это не отдельная утилита, а сервис на стороне VMware. Чтобы начать его использовать, нужно:

1. Перейти по адресу hasimulator.vmware.com.

2. Нажать "Simulate Now", чтобы принять EULA и загрузить дамп DRM, после чего начать процесс симуляции.

3. Нажмите иконку помощи в правом верхнем углу для детальной информации об использовании сервиса.

Где взать DRM-дамп:

• vCenter server appliance: /var/log/vmware/vpx/drmdump/clusterX/
• vCenter server Windows 2003: %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\
• vCenter server Windows 2008: %ALLUSERSPROFILE%\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\

Для больших инфраструктур vRAS - штука полезная и незаменимая.

Как вы знаете, недавно компания VMware сняла эмбарго на освещение новых возможностей платформы виртуализации VMware vSphere 6.0, о которых мы писали вот тут (и тут). На блогах, посвященных технологиям виртуализации, появилось много разных статей о новых возможностях продукта, и мы уже писали о технологии непрерывной доступности VMware Fault Tolerance 6.0.

Сегодня мы хотим рассказать об отказоустойчивых кластерах VMware Virtual SAN 6.0, для которых версия программного обеспечения продвинулась с 1.0 сразу до 6.0 (поэтому пользователи, все же, не должны заблуждаться насчет зрелости продукта - это его вторая версия).

Итак, что нового появилось в VMware Virtual SAN 6.0:

1. Поддержка архитектуры All Flash для создания кластера хранилищ.

Теперь доступны два варианта развертывания VSAN:

• Hybrid – Virtual SAN, как и раньше, использует SSD-диски для кэширования, а для хранения ВМ используются обычные HDD-диски. Максимально возможные конфигурации этой архитектуры стали выше (например, стало 64 хоста в кластере).
• All Flash – Virtual SAN использует имеющиеся Flash-накопители как для кэширования, так для хранения ВМ.

Отличия между данными архитектурами:

В конфигурации All Flash девайсы, ответственные за кэширование, будут производить только кэширование записи и не будут делать кэширование на чтение (это очевидно почему). В гибридной конфигурации, как и раньше, 30% емкости SSD-кэшей используется для Write Buffer, а 70% - для кэша на чтение.

В целом, утверждается, что решение Virtual SAN теперь готово к полноценной промышленной эксплуатации.

2. Возможность High Density Direct Attached Storage (HDDAS).

Теперь кластеры Virtual SAN удобно использовать в окружениях с блейд-системами. Для них поддерживаются как SDD, так и HDD-устройства, включая flash-хранилища блейд-серверов.

Если раньше блейд-системы не очень подходили для организации кластеров ввиду физических ограничений по локальным хранилищам, то теперь это вполне подходящий вариант использования для корпоративной инфраструктуры. Поддержка устройств будет строго контролироваться и постоянно обновляться в VMware HCL.

3. Новая файловая система и формат On-Disk.

Virtual SAN в VMware vSphere 5.5 использовал модифицированный формат файловой системы VMFS с измененным механизмом блокировок, которая называлась VMFS-L. Теперь же в VSAN 6.0 используется файловая система VSAN FS, специально предназначенная для кластеров хранилищ.

Старый формат VMFS-L поддерживается и в новой версии, но VMware предлагает провести миграцию хранилищ, тем более что это делается без простоя сервисов.

4. Функции Proactive Rebalance.

В Virtual SAN 6.0 появилась возможность ребаланса объектов по виртуальным дискам в случае, если подключается новый узел vSphere или если диски заполнены на 80% и более. Делается это через Ruby Console.

5. VSAN Fault Domains (группы отказа).

Теперь в VSAN можно определять домены отказа, то есть группы хостов у которых может произойти одновременный сбой (например, отказ питания на стойке), чтобы все их объекты были задублированы в других доменах:

Теперь реплики объектов происходят не на уровне хостов, а на уровне Fault Domains (в данном случае инфраструктура хранения переживет отказ одной стойки):

6. Новые функции для дисков (Serviceability Functions).

• Light LED on failures – включение LED-индикатора при отказе.
• Turn on disk LED manually - включение LED-индикатора вручную для диска, чтобы его можно было найти на массиве.
• Marking a disk as local – если диск не обнаружился как локальный, его можно пометить вручную из GUI.
• Marking a disk as SSD - теперь эта опция есть в GUI, нужна если диск автоматически не распознается как SSD.

7. Улучшения сетевого взаимодействия.

Теперь Virtual SAN 6 поддерживает конфигурации на уровне Layer 3. Кроме того, теперь доступна конфигурация с Jumbo Frames. Ну и добавлена поддержка возможностей vDS и Network IO Control (NetIOC).

8. Новый тип виртуального диска VMDK - vsanSparse.

Ранее использовались стандартные Redo-диски, но они не были приспособлены под кэширование и другие функции VSAN FS, поэтому сделали новый тип диска vsanSparse.

9. Улучшенные функции Disk/Disk Group Evacuation.

Возможность эвакуации данных с отдельного диска или группы перед тем, как вы его хотите вывести из эксплуатации физически. Ранее приходилось переводить весь хост в Maintenance Mode, чтобы было очень неудобно при поломке лишь одного диска.

10. Новое представление Resynchronization Dashboard.

Это представление показывает статус объектов, которые по тем или иным причинам находятся в состоянии ресинхронизации. Также показывается примерное время окончании синхронизации:

11. Новые службы 3rd Party File Services.

Сторонние вендоры теперь могут надстраивать свои решения над VMware Virtual SAN. Например, мы писали о таком решении совсем недавно - это NexentaConnect.

12. Полноценная поддержка командлетов PowerCLI.

Ранее интерфейс PowerCLI поддерживался неофициально, теперь же командлеты задокументированы и поддерживаются:

13. Службы мониторинга жизнедеятельности (VSAN Health Services).

Теперь для компонентов Virtual SAN доступна информация об их состоянии:

14. Storage Consumption Models.

Возможность визуализовать использование ресурсов хранения Virtual SAN 6.0 при создании или изменении VM Storage Policy.

О доступности VMware Virtual SAN 6.0 будет объявлено отдельно.

Компания StarWind, поставщик ПО номер 1 для создания отказоустойчивых кластеров хранилищ в инфраструктурах VMware vSphere и Microsoft Hyper-V (о возможностях продукта - тут), приглашает на бесплатный вебинар "Microsoft SQL Server deployment price reduced by 3 times with StarWind Virtual SAN". На мероприятии пойдет речь о том, каким образом с помощью продукта Virtual SAN можно сократить затраты на внедрение SQL Server аж в три раза!

Дата и время вебинара: 3 февраля в 19-00 по московскому времени.

Группы доступности SQL AlwaysOn стали отличным решением для тех, кто годами искал средства кластеризации баз данных SQL Server. Теперь хранилища на базе локальных дисков серверов позволяют построить кластер высокой доступности SQL Server с использованием стандартной лицензии и узлов AlwaysOn Failover Cluster.

У такой конфигурации появляются следующие преимущества:

• Не нужно лицензии SQL Server Enterprise
• Упрощенная настройка
• Нет необходимости в дорогостоящем физическом SAN или NAS-хранилище

Теперь можно с помощью обычных серверов и ПО StarWind Virtual SAN построить инфраструктуру кластера SQL Server AlwaysOn с функциями высокой доступности, не приобретая лишнего оборудования и ПО, сэкономив в три раза без потери производительности. Как именно это сделать? Приходите на вебинар StarWind и узнайте!

Как вы знаете, у компании VMware был такой продукт как vCenter Server Heartbeat, который защищал управляющий сервер vCenter от сбоя различных его компонентов и на различных уровнях. Некоторое время этот продукт был снят с производства, и теперь защиту vCenter от сбоев рекомендуется обеспечивать стандартными средствами платформы VMware vSphere.

Надо сказать, что обеспечение надежности сервера vCenter, работающего в виртуальной машине (а сейчас уже мало кто ставит его в физической), начинается с обеспечения доступности и дублирования компонентов, которые находятся "под ним", а именно: хост-сервер ESXi, источники питания, хранилища, сетевые подключения и т.п.

Ну а, собственно, для правильной конфигурации самой платформы vSphere и сервера vCenter, компания VMware выпустила полезный документ "VMware vCenter Server 5.5 Availability Guide".

Итак, начнем с того, что VMware предлагает разделить сервисы vCenter на две большие части:

• Compute Node - это сам vCenter и все сервисы к нему относящиеся (SSO, Web Client, Inventory service)
• Data Node - это узел, где хранятся данные vCenter, попросту говоря, это СУБД и сама база данных.

Понятно, что оба этих компонента могут быть как на одном сервере (для небольшой инфраструктуры), так и в разных машинах, когда требуется производительная база данных (например, в Enterprise-окружениях).

Если у вас большая виртуальная инфраструктура, где есть множество управляющих компонентов, то вы можете выделить отдельный кластер из трех и более хостов чисто под эти нужды.

Но чаще всего у вас есть просто одна или максимум две виртуальные машины - одна под vCenter, вторая - под его базу данных.

Доступность Compute Node

Это раздел включает в себя доступность следующих комопнентов:

• vCenter Single Sign-On services
• vCenter Inventory Service
• vCenter Server
• vCenter Server management Web service
• vSphere Web Client

Здесь рекомендуется настроить защиту средствами технологии VMware HA и придерживаться следующих рекомендаций:

• Создавайте (по-возможности) отдельный кластер для управляющих сервисов - в случае отказа любого из компонентов сервисы будут перезапущены с помощью HA автоматически.
• Включите не только VMware HA, но и технологию virtual machine monitoring, которая отключена по умолчанию. Это позволит перезапустить сервер с vCenter при зависании гостевой ОС.

• Включите и настройте admission control в кластере HA/DRS, где работает vCenter. Это позволит гарантированно перезапустить vCenter на одном из хостов в случае сбоя.
• Установите restart priority в настройках HA для машины с vCenter Server в значение "High". Он будет первым запускаться.
• Если ваш vCenter находится в Windows-машине, то можно настроить автоматический рестарт машины при невозможности после многократных попыток запустить службу vCenter Service.

Выглядеть это может примерно вот так (только помните, что в случае такй настройки, виртуальная машина может впасть в цикл бесконечных перезагрузок).

• Если у вас компоненты vCenter на разных машинах, не забудьте установить правило affinity rule, чтобы машины оказались на одном хосте при миграции и восстановлении, в целях сохранения максимальной производительности управляющего сервиса.
• Также для гарантии можно выделить управляющим компонентам гарантированную физическую память (Memory Reservation) в настройках виртуальной машины.

Доступность Data Node

Тут VMware приводит следующие рекомендации:

• Также, как и в случае с Compute Node, рекомендуется использовать для управляющих сервисов и базы данных отдельный кластер.
• Если вы используете решение для кластеризации vCenter, необходимо убедиться, что настройка ForceAffinePoweron в параметрах vSphere DRS установлена в значение 1, чтобы включать сервер БД, несмотря на правила DRS.
• Так же, как и в случае с Compute Node, используйте технику virtual machine monitoring для перезапуска зависшей гостевой ОС.
• То же самое и про admission control - используйте его для гарантированного восстановления ВМ с сервером БД.
• Аналогично Compute Node, установите restart priority в настройках HA для машины с базой данных в значение "High". Он будет первым запускаться.
• Для защиты vCenter Server SQL Server database можно использовать Microsoft Failover Clustering, который официально поддерживается со стороны VMware. Табличка совместимости СУБД и версий vCenter приведена ниже.

О том, как восстанавливать серверы vCenter, и многом другом можно почитать в документе "VMware vCenter Server 5.5 Availability Guide".

Недавно компания StarWind, выпускающая продукт номер 1 для построения отказоустойчивых программных хранилищ Virtual SAN, выпустила интересный документ "Step-by-Step Guide to building a Windows Server 2012 R2 Failover Cluster using StarWind Virtual SAN V8".

В документе подробно рассказывается о том, как построить кластер отказоустойчивости из хостов Windows Server 2012 R2 на платформе StarWind Virtual SAN. Описанная процедура состоит из следующих этапов:

1. Анализ требований к окружению и их выполнение.
2. Установка ПО StarWind Virtual SAN.
3. Создание и настройка LUN на виртуальном хранилище Virtual SAN. В процессе создания таргета и виртуального диска подробно описываются все настройки и режимы работы устройств.
4. Настройка фичи Failover Cluster feature и запуск валидации кластера.
5. Создание Windows Server 2012 R2 Failover Cluster.

Также на эту тему можно почитать следующие документы:

• What’s New in Failover Clustering in Windows Server 2012 R2
• Failover Clustering Hardware Requirements and Storage Options
• Validate Hardware for a Failover Cluster
• Deploy a Hyper-V Cluster
• Use Cluster Shared Volumes in a Failover Cluster
• Network Recommendations for a Hyper-V Cluster in Windows Server 2012
• Cluster-Aware Updating Overview
• Технические документы StarWind Software

Как убедиться в том, что инфраструктура облачного провайдера действительно не имеет единой точки отказа? Проверить это на деле!

В этой заметке сотрудники ИТ-ГРАД расскажут о том, как они проводили приёмо-сдаточные испытания своей новой облачной площадки.

Предыстория

24 сентября мы открыли новую публичную облачную площадку в Санкт-Петербурге. Вот тут предварительный план испытаний облачной платформы.

И вот мы приступаем…

Удаленное тестирование

1. Поочередное выключение контроллеров FAS8040

Ожидаемый результат... [Читать статью далее]

Оказывается, пару месяцев назад, еще до проходящего сейчас в Барселоне VMworld Europe 2014, компания VMware сделала анонс VMware Site Recovery Manager 5.8 - средства создания катастрофоустойчивой архитектуры виртуального датацентра. Но на днях была обновлена vSphere Replication до версии 5.6, где появилась возможность проводить безопасную репликацию виртуальных машин в облако VMware vCloud Air, поэтому новость про SRM 5.8 сейчас будет очень кстати.

Напомним, что прошлую мажорную версию VMware SRM 5.5 компания VMware выпустила больше года назад.

Новые возможности VMware SRM 5.8:

• Наконец-то SRM полностью поддерживает vSphere Web Client (ранее он был доступен только для "толстого" клиента).

Интерфейс полнофункциональный. Вот, например, автоматическое создание реверсного мапинга на резервной площадке:

• Теперь в рамках создания плана аварийного восстановления можно мапить не только отдельные IP-адреса машин (что неудобно при массовом мапинге), но и целые подсети (IP customisation plans).

• Новая версия vSphere Replication обеспечивает возможность проводить безопасную репликацию виртуальных машин в облако VMware vCloud Air.
• vSphere replication calculator - возможность посчитать, какой канал вам потребуется для репликации нужного числа виртуальных машин.
• Enhanced reporting – в новой версии vSphere Replication появилось новое представление reporting dashboard, которое представляет детальную информацию об использовании vSphere Replication.
• Появился новый плагин VMware Orchestrator Plugin for SRM для автоматизации операций SRM (это необходимо для нестандартных и комплексных сценариев).
• SRM теперь может использовать встроенную базу данных vPostgres для быстрого развертывания.
• Полная поддержка VSAN и vSphere Storage Appliance (VSA).
• Интегрированная Windows-аутентификация при использовании БД Microsoft SQL Server (подробнее тут).
• Поддержка интеграции с vCloud Automation Center (vCAC - сейчас этот продукт называется vRealize Automation) - появились средства самообслуживания пользователей.

Скачать VMware Site Recovery Manager 5.8 можно по этой ссылке. Документация доступна тут, а вот тут - презентация о новых фичах с VMworld.

Не секрет, что на рынке для создания отказоустойчивых программных хранилищ для виртуальных машин есть два лидера - это StarWind Virtual SAN (о котором мы часто пишем) и VMware Virtual SAN (продукт компании VMware для своей платформы vSphere).

В таблице ниже мы решили показать, почему StarWind Virtual SAN во многом лучше VMware Virtual SAN, рассмотрев значимые для администраторов технические критерии выбора продукта. Конечно же, это не все критерии и по каким-то параметрам Virtual SAN от VMware будет работать лучше, кроме того продукты представляют собой различные архитектуры построения отказоустойчивых кластеров, но тем не менее в каком-то ракурсе сравнить их все-таки можно.

Итак:

Более подробно о новых возможностях восьмой версии StarWind Virtual SAN можно узнать вот тут, а тут доступен документ со сравнением платного и бесплатного изданий продукта.

На днях компания VMware сделала неожиданное для некоторых своих клиентов заявление - продукт для защиты серверов VMware vCenter (на уровне различных его компонентов) VMware vCenter Server Heartbeat снят с производства со 2-го июня 2014 года и не будет больше доступен. То есть, для него уже наступил End of Availability (EoA).

На самом деле, этот продукт всегда был каким-то непонятным. Продавали его в довесок к VMware vSphere, а заказчик потом и не знал, что с ним делать - интерфейс корявый, установка сложная, полезность сомнительная. Достаточно просто посмотреть на окно версии vCenter Server Heartbeat 5.5:

По-видимому, не меня одного раздражал этот иконочный привет из девяностых, а развивать продукт было сложно - надо ведь поддерживать как обычный vCenter, так и его линуксового собрата в виде готовой виртуальной машины - VMware vCenter Server Appliance (а его поддержки в Heartbeat не было).

Таким образом, теперь остаются следующие способы защитить сервер управления vCenter от сбоев:

• Использовать виртуальную машину с vCenter Server и защищать ее средствами VMware HA (полностью поддерживается).
• Использовать последние версии vCenter Server Heartbeat (End of Live).
• Использовать кластер MSCS для сервера vCenter (не поддерживается).
• Использовать сторонние решения по кластеризации (не поддерживается).
• Использовать технологию VMware Fault Tolerance (в целом работает, но не поддерживается).

Так что способ защиты vCenter остался, по-сути, только один. Но и ничего страшного - не такая это суперкритичная часть инфраструктуры. Разворачивайте его в виртуальной машине, бэкапьте, включайте в кластер HA, да и все.

Поддержка VMware vCenter Server Heartbeat продлится до сентября 2018 года, поэтому пока можно не волноваться. Об остальном можно прочитать в FAQ на странице продукта.

Как многие знают, с выходом средства для создания отказоустойчивых кластеров хранилищ VMware Virtual SAN, строящихся на базе локальных дисков серверов ESXi, стало известно, что этот механизм интегрирован со средством серверной отказоустойчивости VMware HA.

"Интегрирован" - означает, что любая нештатная ситуация, случившаяся с хостами ESXi должна быть обработана на стороне обоих механизмов, а также решение этой проблемы находится в компетенции поддержки VMware. И правда - ведь отказавший хост ESXi нарушает целостность обоих кластеров, поскольку предоставляет и ресурсы хранилищ, и вычислительные ресурсы.

При этом, например, в случае каких-нибудь сбоев в сети может произойти "разделение" кластеров на сегменты, что может повлечь неоднозначность в их поведении, поскольку они используют разные сети для поддержания кластера (хождения хартбитов).

Например, на картинке представлено разделение кластеров VMware HA и Virtual SAN на два частично пересекающихся сегмента:

Это, конечно же, плохо. Поэтому в VMware vSphere 5.5 были сделаны изменения, которые автоматически переносят сеть хартбитов кластера VMware HA в подсеть VMware Virtual SAN. Это позволяет в случае разделения сети иметь два непересекающихся в плане обоих технологий сегмента:

Вот тут и возникает 3 основных вопроса:

• Какие хранилища нужно использовать в качестве datastore heartbeat?
• Как адрес в случае изоляции хоста (isolation address) нужно использовать, чтобы надежно отличать изоляцию хоста от разделения сети на сегменты (network partitioning)?
• Какие действия в случае изоляции хостов ESXi от остальной сети (isolation responses) нужно использовать?

Ну а в статье на блогах VMware даются вот такие ответы:

1. В качестве хранилищ, использующих datastore heartbeat в данной конфигурации, предлагается использовать датасторы, прицепленные к хостам ESXi, не входящим в кластер Virtual SAN. Объясняется это тем, что в случае разделения сети VSAN, механизм VMware HA сможет координировать восстановление виртуальных машин на хостах через эти хранилища.

2. По поводу isolation address есть следующие рекомендации:

• При совместном использовании Virtual SAN и vSphere HA настройте такой isolation address, который позволит определить рабочее состояние хоста в случае отключения его от сети (сетей) VSAN. Например, можно использовать шлюз VSAN и несколько дополнительных адресов, которые задаются через расширенную настройку das.isolationAddressX (подробнее об этом - тут).
• Настройте HA так, чтобы не использовать дефолтный шлюз management network (если эта не та же сеть, что и Virtual SAN network). Делается это через настройку das.useDefaultIsolationAddress=false.
• Ну и общая рекомендация - если вы понимаете, как может быть разделен кластер с точки зрения сети, то найдите такие адреса, которые будут доступны с любого хоста при этом сценарии.

3. Ну и самое главное - действие isolation response, которое необходимо выполнить в случае, когда хост посчитал себя изолированным от других. На эту тему уже много чего писалось, но VMware объединила это вот в такие таблички:

А теперь, собственно, таблица ниже, которая объясняет от чего зависят последние 2 пункта:

Логика тут в принципе понятна, но в каждой конкретной ситуации может быть масса тонкостей касательно различных сценариев разделения и сбоев в сети, так что эти таблички лишь определяют направление мысли, а не дают готового рецепта.

Мы достаточно часто пишем о средстве для создания отказоустойчивых кластеров VMware Virtual SAN (статьи можно найти по тэгу VSAN). Не так давно мы писали про документ, который позволяет правильно выбрать серверное оборудование для создания кластеров VSAN, а в этой заметке на основе информации от Дункана Эппинга, мы расскажем о выборе дисков для Virtual SAN.

Как известно, на одном хосте VMware ESXi, являющимся узлом VSAN, может быть до пяти дисковых групп (Disk Groups), каждая из которых содержит один SSD-диск и от 1 до 7 HDD-дисков:

Возникает резонный вопрос, что лучше - иметь одну дисковую группу большой емкости или несколько дисковых групп емкостью поменьше. Например, у вас такие требования к кластеру VSAN:

• Всего нужно емкости : 20 ТБ
• Всего емкости флэш-накопителей (10% по best practices): 2 ТБ
• Всего хостов ESXi: 5

В этом случае на каждом хосте можно использовать одну из двух альтернативных конфигураций:

• 2 x 2 ТБ SAS-диска и 1 x 400 ГБ флэш-диск (одна дисковая группа)
• 4 x 1 ТБ SAS-диска и 2 x 200 ГБ флэш-диска (две дисковых группы)

Тут получается три аспекта, на которые влияет выбор конфигурации:

1. SSD-диск+HDD-диски дисковой группы являются единой точкой отказа (fault domain), так как отказ единственного SSD-накопителя приведет к отказу дисковой группы в целом. В случае отказа флэш-накопителя данные вы, конечно, не потеряете, но понадобится некоторое время, чтобы восстановить избыточную конфигурацию. Так что чем больше групп, тем лучше.
2. С точки зрения производительности - также лучше иметь две дисковых группы. Как вы знаете SSD-диск используется для кэширования данных, а один диск большей емкости, хоть и выжимает больше IOPS, но не намного. То есть, в первом случае, например, вы будете получать на кэше 36 000 IOPS, а во втором 2 x 32 000 IOPS. Аналогично, больше иопсов будут выжимать и HDD-диски. Очевидно, второй случай с точки зрения производительности - выгоднее.
3. Затраты - здесь надо балансировать между оптимальной емкостью SSD-накопителей и HDD-дисков. Диски большой емкости, начиная с какой-то точки, стоят намного дороже. Тут второй вариант тоже в плюсе.

Итого - несколько дисковых групп на хосте небольшой емкости лучше одной гигантской дисковой группы.

Тем из вас, кто развернул средство для создания отказоустойчивых кластеров VMware Virtual SAN, может потребоваться мониторинг состояния кластера в разрезе использования различных вычислительных ресурсов на хостах ESXi, а также виртуальными машинами.

Для этого есть специальная утилита с графическим интерфейсом VSAN Observer, которая позволяет через веб-интерфейс наблюдать за кластером VSAN. По умолчанию на сервере VMware vCenter она отключена.

Чтобы включить ее, делаем следующее:

1. Если вы используете VMware vCenter Virtual Appliance, то нужно запустить Ruby-консоль следующей командой:

rvc username@localhost

Здесь вводим логин и пароль администратора vCenter.

Если вы используете vCenter Server для Windows, то эту консоль можно запустить следующим bat-файлом (логин-пароль аналогичны предыдущему пункту):

%PROGRAMFILES%\VMware\Infrastructure\VirtualCenter Server\support\rvc\rvc.bat

2. Используем команды cd и ls, чтобы перейти в рабочий каталог VSAN:

cd localhost

cd VSAN

3. Запускаем веб-сервер VSAN Observer командой:

vsan.observer ~/computers/VSAN --run-webserver --force

4. После этого запускаем консоль VSAN Observer, перейдя по ссылке:

http://<vCenter Server>:8010

На первой вкладке мы видим дэшборд с различными характеристиками хост-серверов VMware ESXi, входящих в состав кластера Virtual SAN:

На вкладке VSAN Disks (per-host) мы видим уже графики на уровне отдельных физических дисков хостов:

На вкладке VSAN Disks (deep-dive) мы смотрим детальные параметры дисков на уровне отдельного хоста ESXi, включая кэширующий SSD-диск и HDD-диски с данными.

Каждый график можно развернуть отдельно, просто нажав на него:

На вкладке PCPU можно отслеживать параметры загрузки процессоров хост-серверов, обслуживающих кластер VSAN:

То же самое, но касательно памяти:

На вкладке Distribution можно смотреть информацию относительно баланса кластера - равномерно ли загружены его ресурсы:

Вкладка DOM Owner похожа на первую вкладку - говорят она для техподдержки VMware:

А вот вкладка VMs - полезная штука. Тут можно смотреть за производительностью на уровне отдельных виртуальных дисков конкретных ВМ, использующих ресурсы хранения кластера VSAN.

Также тут можно узнать, на каких хостах находятся реплики виртуальных дисков VMDK конкретной ВМ:

Ну а если вы хотите использовать VSAN Observer на сервере VMware vCenter под Windows, то команда ниже позволит вам добавить соответствующее правило в его сетевой экран:

netsh advfirewall firewall add rule name = "VMware RVC VSAN Observer" dir = in protocol = tcp action = allow localport = 8010 remoteip = localsubnet profile = DOMAIN

Интересная новость пришла с конференции EMC World 2014, которая проходила с 5 по 8 мая в Лас-Вегасе. Теперь при построении распределенного ("растянутого") кластера VMware HA/DRS (он называется vSphere Metro Storage Cluster, vMSC) поддерживается задержка RTT (Round Trip Time) в канале до 10 миллисекунд. Для такого варианта использования сертифицировано решение VPLEX Geosynchrony 5.2, начиная с версии VMware vSphere 5.5.

Надо сказать, что технология EMC VPLEX Metro ранее поддерживалась на расстояниях между ЦОД в диапазоне до 100-150 км (иногда несколько более), где возникают задержки (latency) до 5 мс (это связано с тем, что RTT-время пакета в канале нужно умножить на два для FC-кадра, именно два пакета необходимо, чтобы донести операцию записи). Но и 150 км - это вовсе немало. Теперь же это расстояние увеличилось до 300 километров.

Ранее технология vMotion поддерживалась и для latency до 10 мс, а вот механизм отказоустойчивости VMware HA гарантированно работал только для задержек до 5 мс.

При этом сейчас кластер vMSC сертифицирован как для нативного плагина доступа к хранилищам NMP (Native Multi-pathing), так и для плагина PowerPath/VE. Здесь надо обязательно отметить, что данная конфигурация поддерживается только издания VMware vSphere Enterprise Plus.

Более подробная информация о кластерах vMSC приведена в KB 2007545.

Долгожданная новость от компании StarWind: вышла восьмая версия продукта для создания отказоустойчивых кластеров хранилищ - StarWindV8! Решение теперь называется StarWind Virtual SAN, и, как и раньше, оно доступно для двух платформ - VMware и Hyper-V. Cкоро мы напишем о новой версии этого продукта весьма детально.

Тем же из вас, кто находится сейчас на глобальной конференции Microsoft TechEd 2014, проходящей в Хьюстоне, мы настоятельно рекомендуем заглянуть на стенд компании StarWind Software (номер #746) по двум причинам:

• Вам покажут живое демо продукта StarWind V8, который уже вышел и доступен для загрузки.
• Расскажут о том, как наполовину снизить издержки на содержание инфраструктуры небольшой организации или филиала при удвоении эффективности.

В выпущенной еще в прошлом году версии платформы виртуализации VMware vSphere 5.5 компания VMware представила решение App HA, которое выросло из функций  VM Monitoring, средствами которых можно было обнаруживать недоступность отдельной ВМ и перезапускать ее в случае сбоя. Потом эти возможности решили применить и к отдельным приложениям, в результате чего и появилось решение App HA:

Теперь App HA поддерживает некоторое количество приложений, поведением по "лечению" которых можно управлять на базе политик.

В середине апреля было выпущено решение VMware App HA 1.1, в котором появилось несколько новых возможностей:

• Теперь из коробки поддерживается больше приложений: Oracle (10g и 11g), а также PostgreSQL (8.x и 9.x).
• Поддержка любого сервиса: теперь агенты Hyperic можно использовать для любого сервиса в гостевой ОС (старт/стоп сервиса).
• Улучшенная совместимость с разными версиями vSphere - поддерживается как vSphere 5.5, так и 5.1.
• Возможность гибкого редактирования политик App HA, в том числе тех, которые уже назначены различным сервисам.
• Добавлено 6 языков, русского, к сожалению, нет.

Таким образом, решение App HA поддерживает мониторинг следующих приложений в гостевых ОС виртуальных машин:

А вот табличка совместимости App HA с различными компонентами VMware vSphere:

Полезные ссылки:

• Скачать App HA
• Документация
• Release notes
• Руководство по установке
• Гайд по совместимости